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METHOD AND APPARATUS FOR PERFORMING 
ADJUSTABLE PRECISION EXCEPTION HANDLING 



The subject invention relates generally to the field 
of computers and computer software and, more particularly, 
to program code conversion methods and apparatus useful, 
for example, in code translators, emulators and 
accelerators which encounter exception signals. 

An exception is a condition that changes the normal 
flow of control in a program. An exception may be 
generated ("raised") by hardware or software. Hardware 
exceptions include such signals as resets, interrupts, or 
signals from a memory management unit. Exceptions may be 
generated by an arithmetic logic unit or floating-point 
unit for numerical errors such as divide-by-zero, for 
overflow or underflow, . or for instruction decoding errors 
such as privileged, reserved, trap or undefined 
instructions. Software exceptions are varied respectively 
across various software programs and could be applied to 
any kind of error checking which alters the normal 
behaviour of the program. An exception handler is special 
code which is called upon when an exception occurs during 
the execution of a program. If the program does not 
provide a handler for a given exception, a default system 
exception handler will be called, usually resulting in 
abortion of the program being run and an error indication 
being returned. 

Exception signals are a common mechanism for raising 
exceptions on many operating systems. The POSIX standard, 
which is adhered to by _ many operating systems, 
particularly Unix-like systems, specifies how ' this 
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mechanism should behave so that exception signals are 
broadly similar across many systems. The most common 
events that trigger exceptions are when . a - process 
implemented by a program tries to (i) access an unmapped 
5 memory region or (ii) manipulate a memory region for whxch 
it does not have the correct permissions. Other common 
events that trigger exception signals are (iii) the 
receipt of a signal sent from another process, (iv) the 
execution by a process of an instruction that -the process 
10 does not have the privilege level to execute, or (v) an 
I/O event in the hardware. 

Due to the interruption of the program being executed, 
the delivery of an exception signal by the operating 

15 system to an exception handler normally includes a 
captured state of the subject processor when the exception 
occurred. This state can be very difficult to determine 
and costly to generate. In order to avoid these costs, it 
is generally preferable to avoid intentionally issuing 

20 exceptions unless there are no better alternatives. 

Some representative exception signals issued by 
operating systems to define certain events are described 
in Table 1 . _ 
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Signal 


Description 


SIGHUP 


"Hangup" - commonly used to indicate to a process that 
its configuration has changed, and that it should re-read 
its config file. 


SIGINT 


"Interrupt" - usually means Ctrl-C has been pressed by 
the user. 


SIGILL 


."Illegal Instruction" - the processor generates this when 
an. invalid instruction opcode is encountered. 


SIGTRAP 


"Breakpoint" - often used by debuggers. 


SIGBUS 


"Bus Error" - usually generated by the processor to 
indiCcitc an j.nvs.1 id memory access . This ils usually an 
access to an unallocated or unaligned memory address. 


SIGSEGV" 


"Segmentation Violation" - generated by the processor 
when a user process has tried to do something not 
permissible in user mode. For example, trying to execute 
a privileged instruction, or trying to write to part of 
the kernel memory would both raise this signal . 


SIGALRM 


"Alarm Clock" - a process can make the alarm () system 
call, which requests the' delivery of this signal n 
seconds later. 


SIGTERM 


"Terminate" - polite request for a program to think about 
exiting, if it's not too inconvenient. 


SIGQUIT 


"Quit" - Firm request for a program to exit, now please! 


SIGKILL 


"Die"- immediately terminates the process. This signal 
cannot be intercepted by a signal handler. 



Table 1: Exception Signals 



5 Exception signals can come from two. sources: (1) 

directly from a subject program or (2) from the operating 
system or another process. Some exception signals are 
generated as a direct result of an instruction executed by 
the subject program. For example, if a subject program 
10 . executes an illegal opcode, then SIGILL is raised. 
Similarly, if the . subject program attempts an illegal 
memory access then SIGSEGV is raised. These are referred 
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to as in-band signals. Exception signals can also be 
generated externally, either by the operating system or by 
another process. SIGHUP and SIGALRM are examples of 
these. These externally generated exception signals aire 
5 called out-of-band signals. 

From a subject program's point of view, an exception 
signal can occur at any time. When an exception signal 
occurs, the operating system interrupts the execution of 

10 the signaled program and invokes a signal handler 
function. The operating system maintains a process - 
specific function table which maps each signal to a 
particular signal handler. The operating system also 
defines default signal handlers for all. exceptions. The 

15 default signal handlers either take predefined actions or 
simply ignore the signal. 

For example, in Unix, a program can override a default 
signal handler by invoking the sigactionO system call. 

20 SigactionO allows the program to specify what action the 
operating system should take when a particular exception 
signal is received. The action can be: (1) ignore the 
exception signal; (2) call the default signal handler; or 
(3) call a specialized signal handler function, whose 

25 address is provided by the program. Other options that 
can be specified when making the sigactionO call include 
- which other signals are blocked during execution of a 
signal handler, in much the same way as a CPU can mask 
certain interrupts. 
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A Unix signal handler can be provided with one of two 
prototypes. The first signal handler prototype is "void 
sigHandler (int sigNum)." The first argument is the number 



of 'the exception signal, so that one function can be 
registered to handle multiple signals. A program can 
request that more information be provided to the signal 
handler by calling sigactionO with the SA_S1G1NF0 flag. 
In this case, the Unix signal handler prototype becomes 
"void sigHandler (int sigNum, siginfo__t siglnfo, void 
* context) . " 

The second parameter ("siginfo") is a structure which 
contains information about the signal, including some 
indication of what caused the signal and where it came 
from. For example, in the case of a SIGILL signal, the 
siginfo structure contains the address of the illegal 
instruction. This data can be essential to allow the 
process to handle the signal properly. The third 

parameter ("context") provides access to the processor 
state (including all subject registers) at the time the 
signal was raised. Again, this data can be essential to 
allow correct handling of a signal. The signal handler is 
allowed to modify this context; when execution is resumed, 
the subject registers are then restored to the values of 
the modified context. 

In both embedded and non-embedded CPU's, one finds 
predominant Instruction Set Architectures (ISAs) for which 
large bodies of software exist that could be "accelerated" 
for performance, or "translated" to a myriad of capable 
processors that could present better cost /performance 
benefits, provided " that they could transparently access 
the relevant software. . One also finds dominant CPU 
architectures that are locked in time to their ISA, and 
cannot evolve in performance or market reach. Such 
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architectures would benefit from "Synthetic CPU" co- 
architecture . 

Program code conversion methods and apparatus 
5 facilitate such acceleration, translation- and co- 
architecture capabilities and are addressed, for example, 
in the co-pending patent application, GB 03 09056.0, filed 
on 22 April 2003, entitled Block Translation Optimization 
for Program Code Conversion, the disclosure of which is 
10 hereby incorporated by reference into the present 
application. Exception handling is one attribute of many 
subject programs which may be encountered in the course of 
program code conversion. 

15 According to the present invention there is provided 

an apparatus and method as set forth in the appended 
claims. Preferred features of the invention will be 
apparent from the dependent claims, and the description 
which follows. 

20 

The following is a summary of various aspects and 
advantages realizable according to various embodiments 
according to the invention. It is provided as an 

introduction to assist those skilled in the art to more 
25 rapidly assimilate the detailed design discussion that 
ensues and does not and is not intended in any way to 
limit the scope of the claims that are appended hereto. 

in particular, the inventors have developed methods 
-3 0 directed at expediting program code conversion, 
particularly useful in connection with a run-time 
translator which employs translation of subject program 
code into target code. According to one aspect of the 



following description, an adjustable precision exception 
handling technique is providing for handling exceptions 
encountered during execution of translated subject code at 
varying levels of precision, depending upon the particular 
type of exception encountered. As an exception signal is 
detected by the translator, the state of the subject 
processor is captured at a level of precision determined 
to be sufficient for the detected exception and the 
corresponding signal handling behavior of the subject 
program. 

The accompanying drawings, which are incorporated in 
and constitute a part of the specification, illustrate 
presently preferred implementations and are described as 
follows: 

Figure 1 is a block diagram illustrative of apparatus 
wherein embodiments of the invention find application; 

Figure 2 is a schematic diagram illustrating a first 
exception signal handling process; 

Figure 3 is a schematic diagram useful in illustrating 
exception signal handling processes in accordance with an 
illustrative embodiment of the invention; 

Figure 4 is a schematic diagram illustrating a second 
exception .signal handling process; and 

Figure 5 is a schematic diagram useful in illustrating 
an exception signal handling process in accordance with an 
illustrative embodiment of the invention. 
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Illustrative apparatus for implementing various novel 
features discussed below is shown in Figure 1. Figure 1 
particularly illustrates a target processor 13 including 
target registers 15 together with memory 18 storing a 
5 number of software components 17, 19, 20, 21 and 22. The 
software components include subject code 17 to be 
translated, an operating system 20, the translator code 
19, and the translated code 21. The translator code 19 may 
function, for example, as an emulator translating subject 
10 code of one ISA into translated code of another ISA or as 
an accelerator for translating subject code into 
translated code, each of the same ISA. 

The translator 19 includes a variable precision 
15 exception handling mechanism 22, which includes a proxy 
signal handler 125. As described below, the mechanism 22 
registers the proxy signal handler 125 in the target code 
21 for exception handling purposes. The translator 19 may 
also generate a translated subject signal handler 12 7 for 
20 exception signal handling purposes. 

The translator 19, i.e., the compiled version of the 
source code implementing the translator, and the 
translated code 21, i.e., the translation of the subject 

25 code 17 produced by the translator 19, run in conjunction 
with the operating system 2 0 such as, for example, UNIX 
running on the target processor 13, typically a 
microprocessor or other suitable computer. It will be 
appreciated that the structure illustrated in Figure 1 is 

3 0 exemplary only and that, for example, software, methods 
and processes according to the invention may be 
implemented in code residing within or beneath an 
operating system. The subject code, translator code, 
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operating system, and storage mechanisms may each be any 
of a wide variety of types, as known to those skilled in 
the art . 

5 • In overall operation of -apparatus according to the 
illustrative embodiment of Figure 1, program code 
conversion is preferably performed dynamically, at run- 
time, while the translated code 21 is running. The 
translator 19 runs inline with the translated program 21. 

10 If an exception signal handler is registered, by the 
subject code 17, the translator 19 is designed to 
translate and execute that exception signal handler on 
receipt of the corresponding exception signal. In so 
doing, the translator 19 is designed to correctly emulate 

15 the semantics of the subject operating system by keeping 
track of which respective translated portions of the 
subject code 17 ' to execute upon the receipt of the 
respective exception signals. In addition, the same 
exception signal may have different signal numbers on 

20 different architectures, so that emulation may include 
translation of signal numbers. The translator 19 is 
further preferably operable to detect a subject program 
exception during decoding of the subject code 17. In such 
case, the translator 19 may then simply invoke the 

25 appropriate subject signal handler at the appropriate time 
rather than raising an actual exception signal. 

The translator 19 further populates the siginf o data 
structure if that data structure is used by the subject 
30 signal handler. Likewise, the translator 19 populates the 
sigcontext data structure if that data structure is used 
by the subject signal handler. As noted above, the 
sigcontext data structure contains a snapshot of the 
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subject processor state at the time of the exception 
signal. Since some signals, such as SIGSEGV,. can be 
raised by almost any instruction, populating the , 
sigcontext structure requires that the translator 19 be 
able to correctly regenerate the entire subject processor 
state from an arbitrary point within a block of sub 3 ect 
code 17. The ability to recreate the entire subject 
processor state is referred to as "precise exceptxon 
handling." Precise exception handling is very difficult 
for a dynamic translator to support without significant 
performance losses . 

As noted above, in cases where a subject code 17 
registers an exception .signal handler, the translator 19 
is designed to emulate the semantics of that signal 
handler. In most cases, a subject code exception signal 
handler is not executable on the target architecture and 
is not responsive to target exception signals. In order 
to accommodate this incompatibility, the translator 19 
includes a proxy signal handler 125, which the translator 
19 registers in the target program 21when, for example, a 
system call for a subject system handler is detected in 
the subject program. 

The proxy signal handler 125 is invoked by and 
intercepts signals from the target operating system 20 and 
constructs the appropriate subject context which will be 
needed by the translated signal handler 127. The proxy 
signal handler 125 then calls the translator 19, which 
then invokes the appropriate (translated) subject signal 
handler . 



Alternatively, if the translator 19 detects at decode- 
time that a particular subject code instruction will- raise 
an exception signal, the translator 19 plants target code 
which constructs the target context (133, Figure 5) and 
invokes the proxy signal handler 125 directly. The 
subject state is again recreated by 'the proxy signal 
handler 125 using several sources, including the 
representation of the subject 'processor state maintained 
by the translator 19 and the target processor state (133) 
passed to the proxy, handler 125, as described further 
below. This "detect at decode- time" approach prevents an 
actual exception signal from being raised by the target 
operating system 20, and hence simplifies operation. 

Figure 2 shows the control flow of signal handling 
which occurs when a program is running on its subject 
architecture. Figure 3 shows signal handling for a 
translated program using the target operating system 
signal handling mechanism of a present embodiment. 

In the signal handling scenario of Figure 2, signal 
handling begins when the subject program 101 raises an 
exception signal 111, which transfers control to the 
operating system 103. The operating system 103 constructs 
a context structure 113 which reflects the state of the 
subject processor when the exception signal 111 occurred. 
The context structure is then passed to the signal handler 
105 that was registered for the particular exception 
signal 111. When the signal handler 105 completes its 
operation, the context structure 113' is returned to the 
operating system 103 . The operating system 103 then 
restores the processor state from the context 113' and 
returns control to the program 101. Any changes to the 
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context structure 113 (e.g., to a register value) made by 
the signal handler 105 will be reflected in the processor 
state when the program 101 resumes execution. In Figure 
2, the apostrophe at the end of the context structure 
5 designation "113" indicates that the contents of the 
context structure may have been modified. 

Figure 3 illustrates the control flow of signal 
handling in a translated program 21 executed by the target 

10 processor 13.. using the exception signal handling 
mechanism 22. To emulate signal handling, the translator 
19 first registers a proxy signal handler function 125 for 
the translated program 121. When an exception signal 131 
occurs in the translated program 121, the target operating 

15 system 20 invokes the proxy signal handler 125 and passes 
it the target context 133. The proxy signal handler 125 
uses the target context 13 3 and a subject register bank 
141 to construct the subject context 135. 
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The translator 19 then identifies, translates, and 
executes the corresponding subject program signal handler 
127 using the reconstructed subject state 135. In 
particular, in the illustrative embodiment, the translator 

19 adjusts the subject state of the handler 127 such that, 
25 when the handler 127 begins executing, its parameters 

point to the reconstructed subject state 13 5. When the 
subject signal handler 127 completes it operation, the 
. subject context 135' is returned to the proxy signal 
handler 125. When the proxy signal handler 125 completes 
its operation, it returns the target context 133' to the 
target operating system 20. The target operating system 

20 then restores the target processor state using the 
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target context 133' and resumes execution of the 
translated subject code 121. 

The subject register bank 141, otherwise referred to 
as a global register store, is a memory region that is a 
repository for abstract registers, each of which 
corresponds to' and emulates the value of a particular 
subject register or other architectural feature. During 
the execution of translated code 21, abstract register 
values are stored alternatively in the subject register 
bank 141 or in target registers 15 (Figure 1) . During the 
execution of translated code 21, abstract registers are 
temporarily held in the target registers 15 so that they 
may participate in instructions. Subject register values 
are saved in the subject register bank 141 when they are 
not being held in the target registers 15. For example, 
if the register allocation for a particular block of 
subject code requires a subject register value to be 
spilled (i.e., saved to memory in order to free a target 
register) , the value is spilled to a reserved location 
within the subject register bank 141 that corresponds to 
that particular subject register. Likewise, all subject 
register values are saved back to the subject register 
bank 141 at the end of each block of subject code, as 
target register values may be overwritten between 
successive blocks. The various features associated with 
creating and using a subject register bank 141 or global 
register store are described in detail in the 
aforementioned in the co-pending patent application, GB 
03 09056.0, filed on 22 April 2003, entitled Block 
Translation Optimization for Program Code Conversion. 



14 



In cases where the translated subject signal handler 
127 modifies the subject context 135, the proxy signal 
handler 125 saves the modified values to the subject 
register bank 141. In Figure 3, the apostrophe at the end 
of subject context designation "135"' indicates that the 
contents may have been modified. If, at the time the 
exception signal was raised, any of those subject register 
values were live in target registers, the proxy signal 
handler 125 also updates the corresponding entries in the 
target context 133, In Figure 1, the apostrophe at the 
end of target context designator "133"' again indicates 
that the contents may have been modified. 

As discussed in greater detail hereafter, depending on 
the level of precision required by the subject signal 
handler 127, the translator 19 may plant target code 
immediately preceding an instruction which raises an 
exception, which target code rectifies and spills all 
subject register values to the subject register bank 141. 
This guarantees that the values retrieved from the subject 
register bank 141 by the proxy signal handler 125 are 
accurate, and that the subject context 135 passed to the 
translated subject signal handler 127 is accurate. 

Figure 4 illustrates signal handling when a program is 
running on its subject architecture in the case where the 
signal handler 105 does not modify the subject context 
113. In the subject architecture signal handling scenario 
of Figure 4, signal handling begins when the subject 
program 101 raises an exception signal 111, which 
transfers control to the operating system 103. The 
operating system 103 constructs a context structure 113 
which reflects the state of the processor when the 



exception the signal 111 occurred. The context structure 
113 is then passed to the signal handler 105 that was 
registered for the particular exception signal 111. When 
the signal handler 105 completes it operation, it returns 
control to the operating system 103. The operating system 
103 then returns control to the program 101. 

Figure 5 illustrates the control flow of signal 
handling for a translated program 121, using direct 
invocation of the proxy signal handler 12 5 by target code, 
and in which the translated subject signal handler 12 7 
does not modify the subject context 135. At the point in 
the translated program 121 where the exception signal 
would have occurred, the target code 21 constructs a 
target context 13 3 and invokes the proxy signal handler 
125, passing it the target context 133. "The proxy signal 
handler 125 uses the target context 133 and the subject 
register bank 141 to construct the subject state 135 as a 
subject context structure. The translator 19 then 

identifies, translates, and executes the corresponding 
subject program signal handler 127, again using the 
reconstructed subject context (state) 135. When the 
subject signal handler 127 completes its operation, it 
returns control to the proxy signal handler 125. When the 
proxy signal handler completes its operation, it returns 
control to the translated subject code 121, which resumes 
execution . 

As noted above, recreating the subject processor state 
can be both difficult and expensive. First, there is an 
actual cost associated with calculating and collecting the 
subject state. For example, translator optimizations such 
as lazy evaluation may' postpone the calculation of subject 
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register values by storing the underlying data necessary 
to calculate those values. Recreating the subject state 
in response to a signal requires those values to be 
rectified (i.e., calculated) immediately. Even if the 
5 subject registers have been calculated previously, they 
must be retrieved from memory, such as from a subject 
register bank. 

Second, there is an opportunity cost associated with 

10 the capability of calculating the subject state at any 
point in the subject program. Many key optimizations in a 
dynamic binary translator involve departures from a strict 
model of binary compatibility. Binary compatibility means 
that the translator can recreate the exact state of the 

15 subject architecture. A strict model is one in which the 
subject state can be recreated at any point in the 
translated program (i.e., at any subject instruction). In 
order to preserve the information necessary to recreate 
the subject state at any point in execution, the 

20 translator must forego significant optimizations. When 
those optimizations are in use, the translator has no way 
to recreate the subject context accurately. Thus, the 
real cost of exceptions is not generating the state when 
the exception occurs but being able to generate the state 

25 at all. 

To address such concerns, the preferred translator 19 
emulates exceptions using a variable precision exception 
handling mechanism 22, whereby the subject context, e.g., 
30 135, is reconstructed at different levels of detail for 
different exceptions, depending on the requirements of the 
particular exception. The translator 19 detects subject 
exceptions either at decode-time or when encountered 



during translation, determines the precision required for 
the subject context for a particular exception, and sets 
an appropriate flag. Generally, the translator 19 can 
determine at decode-time what level of precision is 
required. By comparison, a naive translator is 

inefficient and would implement the most conservative 
solution to allow for the possibility that a complete and 
precise subject context might be needed at any point. 

In. one embodiment, the variable precision exception 
handling mechanism 22 provides exception handling at four 
levels of subject context precision: (0) no state; (1) the 
last known consistent stack frame; (2) precise program 
counter; and (3) full rectified subject registers. As 
noted, the cost of rectifying all subject registers is 
very high and is therefore avoided if at all possible. 
Therefore, the translator 19 handles each exception at the 
lowest level of precision necessary. While this 

embodiment of the variable precision exception handling 
mechanism 22 describes four levels of subject context 
precision, it is possible for the variable precision 
exception handling mechanism 22 to select any level of 
precision from any number of possible levels of precision. 
Furthermore, the particular components of the subject 
context being captured for each level of precision can 
also be variably selected. 

Table 2 illustrates the operations .. performed by 
different translator components for each of the four 
exception handling precision levels, LEVEL 0 through LEVEL 
3, for the illustrative embodiment. The particular 

operations for each level are described in further detail 
below. 
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Level 0 


Level 1 
(Default) 


Level 2 


Level 3 


Decoding 






save PC 


save PC 


_ 


_ 




rectify/spill 
(IR) 


Target 
Code 


- 


- 


- 


rectify subj 
regs 








spill subj 
regs 


exception 


exception 


exception 


exception 


Proxy 

Signal 

Handler 




load PC 
(vague) 


load PC 
(precise) 


load PC 
(precise) 




load stack 
f r ame 
(vague) 


load stack 

frame 

(vague) 


load subj 
regs 

(precise) 


translate/i 
nvoke 
subj ect 
handler 


trans late /inv 
oke 

subject 
handler 


trans late/ inv 
oke 

subject 
handler 


translate/ inv 
oke 

subj ect 
handler 








save subj 
regs 








modi f y target 
regs 



Table- 2: Variable Precision Exception Handling 



Level Zero: No State 

In some cases, the translator 19 determines that no 
subject state is necessary to handle an exception. In 
these cases, the subject context 135 passed to the 
translated signal handler 127 need not contain any 
accurate processor state data. For example, in the Linux 
operating system, exception signal number 31 is reserved 
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for the "Pthread" threading library. This signal is sent 
from a newly created child thread to its parent to signify 
successful creation. The implementation of the Pthread 
library indicates that the handler 127 requires no state 
5 whatsoever, rather, the act of delivering of. the exception 
itself is the only data required. 

Level One: Last Known Stack Frame 

10 Another level of precision is to provide the last 

known stack frame, meaning the last known consistent 
values of the stack pointer, base pointer, and program 
counter (PC) registers. In most situations, it is most 
efficient to make the last known stack frame the default 

15 level of precision. The remaining, undefined values in 
the subject context 135 are filled in with a special 
value, such as " Oxdeadbeef , " for debugging purposes. 

These values are imprecise in that they demonstrate 
20 the last known consistent state of the subject program and 
may not precisely reflect the current state. In one 
embodiment of the translator 19, the last known consistent 
state corresponds to the last basic block boundary, as 
generally all subject registers are rectified and saved to 
25 the subject register bank between basic blocks. The "last 
- known stack frame" level of precision requires no 
rectification of subject register values. 

Level Two: Precise Program Counter 

30 

Level 2 precision is applied in cases where the 
translator 19 determines at decode-time that (a) a 
particular subject instruction will trigger an exception 



signal and (b) the subject signal handler will require a 
precise program counter value. For example, on the x86 
processor, the IRET instruction can only be executed at 
certain privilege levels; if the translator 19 encounters 
this instruction at a time when the subject privilege 
]_ eve ]_ i s too low, proper emulation requires that the 
corresponding subject signal handler be invoked, and that 
the signal handler be passed a precise value for the 
subject program counter. 

The translator 19 emulates such instructions by 
intentionally raising the correct exception or by invoking 
the subject signal handler directly at the appropriate 
location. During translation, the translator 19 records 
the subject address of the instruction that will cause the 
exception in a temporary abstract register. The 
translator 19 also sets a flag to indicate the exception 
handling precision level, so that the proxy signal handler 
125 will know how much context to construct when it is 
subsequently invoked. In case of Level Two, a "precise 
program counter" flag tells the proxy signal handler 125 
to retrieve the precise program counter value. The 
translator 19 then plants target code to raise the 
appropriate exception (normally SIGILL on Unix systems 
including Linux) or to invoke the subject signal handler 
127 directly. When the proxy signal handler 125 is 
invoked, it detects that the "precise program counter" 
flag is set and retrieves the program counter value PC 

: l . . i 

t 

from its stored location. 
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Level Three: Precise Subject Registers 

Level 3, the highest precision level of the embodiment 
under discussion, is used where the translator 19 detects 
5 at decode time that an instruction will cause an exception 
and will require context beyond the value of the program 
counter PC. In some cases, the translator 19 determines 
at decode-time that a particular instruction in the 
subject code 17 will cause an exception and that the 
10 exception handling will require some state beyond the 
program counter. In this case, at decode-time, the 
translator 19 both records the precise program counter 
value PC (subject address) of the excepted instruction and 
generates code to force all subject register values to be 
15 rectified prior to the excepted instruction. This allows 
the translator 19 to generate the full subject context 
when the exception is raised. In addition, in a system 
operating in a block translation mode, the translator 19 
marks the block of code containing the exception such 
20 that, during code generation, certain optimizations are 
not applied. In other words, some optimizations involving 
code motion can cause the subject register values to be 
temporarily (i.e., at certain points in the target code) 
inconsistent with the subject state even if rectified; 
25 these optimizations are turned off for blocks that contain 
exceptions, to guarantee the accuracy of the subject state 
passed to the translated subject signal handler 127. 

For example, the x8 6 INB instruction is used by some 
3 0 subject programs to emulate hardware accesses. The 
subject exception signal handler in this case requires 
precise values for all subject registers (i.e., the full 
context) . When an x86 INB instruction is encountered 
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during translation (decoding) , the translator 19 inserts 
target code (or IR, which is later emitted as target code) 
to rectify all lazy or pending subject register values and 
then spill them to the subject register bank 141. The 
translated block will thus comprise rectification code, 
spill code, and an exception-raising target instruction. 
During the subsequent execution of the translated block, 
the subject state is rectified and spilled before the 
exception is raised, such that the values in the subject 
register bank 141 are consistent and accurate when the 
proxy signal handler 125 is invoked. 



The proxy signal handler 125 constructs the subject 
context 135 using the rectified values in the subject 

15 register bank 141, and constructs the siginfo structure 
from the stored address of the instruction that raised the 
signal. The proxy signal handler 125 then translates the 
subject signal handler 12 7 and invokes it with the siginfo 
structure and context structures 135. When the subject 

20 signal handler 127 finishes execution, it returns control 
to the proxy signal handler 125. When the proxy signal 
handler 125 finishes execution, control returns to the 
translated program 121. 

25 In rare cases, the subject signal handler 127 modifies 

some of the subject registers in the context structure 
135. In this case, the proxy signal handler 125 copies 
those modified values back into the subject register bank 
141 prior to returning control. This ensures that any 

30 modified subject register values are propagated into the 
translated program 121. An example of such a case would 
be a subject signal handler which detects all "divide-by- 



zero" exceptions and responds by setting the result to 
zero and jumping over the "divide" instruction. 

In the illustrative embodiment, the translator 19 
determines the level of precision based on the source of 
the exception signal, the signal number and the particular 
operating system 21 being used. In this context, there 
are three "sources" of exception signals (1) detected at 
decode time (2) caused by execution of target code and (3) 
caused by an external event. In the illustrative 

embodiment, external events including asynchronous 
external events are always assigned a default level of 
LEVEL 1. LEVEL 1 also serves as a default level of 
handling for sources (1) and (2) . 

Regardless of the precision level used, if the 
exception signal is the result of a memory access, the 
translator 19 also fills in the corresponding subject 
address that caused the exception. This value is derived 
from the target state passed to the proxy handler 125, or 
encoded in the target code which invokes the subject 
signal handler 127. Depending on the memory models of the 
subject code 17 and target code 21, the translator 19 may 
need to demangle the target address of the memory access 
to obtain the corresponding subject address. 

Although a few preferred embodiments have been shown 
and described, it will be appreciated by those skilled in 
the art that various changes and modifications might be 
made without departing from the scope of the invention, as 
defined in the appended claims. 
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Attention is directed to all papers and documents 
which are filed concurrently with or previous to this 
specification in connection with this application and 
which are open to public inspection with this 
5 specification, and the contents of all such papers and 
documents are incorporated herein by reference. 

All of the features disclosed in this specification 
(including any accompanying claims, abstract and 
10 drawings), and/or all of the steps of any method or 
process so disclosed, may be combined in any combination, 
except combinations where at least some of such features 
and/or steps are mutually exclusive. 

15 Each feature disclosed in this specification 

(including any accompanying claims, abstract and drawings) 
may be replaced by alternative features serving the same, 
equivalent or similar purpose, unless expressly stated 
otherwise. Thus, unless expressly stated otherwise, each 

20 feature disclosed is one example only of a generic series 
of equivalent or similar features. 

The invention is not restricted to the details of the 

foregoing embodiment (s) . The invention extends to any 
25 novel one, or any novel combination, of the features 

disclosed in this specification (including any 

accompanying claims, abstract and drawings), or to any 

novel one, or any novel combination, of the steps jd± any 
method or process so disclosed. 
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Claims 



1. A method of handling exceptions encountered during 

the translation of subject program code into target code, 
comprising: 

detecting the occurrence of an exception; 

selecting a level of subject context precision 
required for the detected exception from a plurality of 
possible levels of precision; and 

invoking a signal handler to handle the detected 
exception using the selected level of precision. 

2. The method of claim 1, wherein the exception 
occurrence detecting step detects the occurrence of an 
exception signal during translation of the subject program 
code . 

3. The method of claim 2, wherein the target code 
generated by the translation invokes a proxy signal 
handler to handle the detected exception. 

4. The method of claim 1, 2 or 3, wherein the 
exception occurrence detecting step detects the occurrence 
of an exception signal during execution of the target 
code . 

5. The method of claim 4, wherein a target operating 
system invokes a proxy signal handler to handle the 
detected exception . 



6 . The method of any preceding claim, wherein the 

default level of subject context precision is a last known 
stack frame. 

7. The method of claim 6, wherein the last known 
stack frame includes a last known stack pointer value, a 
base pointer value, and a program counter register value. 

8. The method of claim 7, wherein said default level 
of subject context precision requires no rectification of 
subject register values. 

9. The method of any preceding claim, wherein one of 
said possible levels of subject context precision is no 
subj ect state . 

10. The method of any preceding claim, wherein one of 
said possible levels of subject context precision is a 
precise program counter state including a precise program 
counter value. 

11. The method of any preceding claim, wherein one of 
said possible levels of subject context precision is a 
precise subject register state including rectified subject 
registers and a precise program counter value. 

12. In a method of handling subject code exceptions in 
a translation system employing a translator to translate 
subject code to target code, the steps comprising: 



generating a target context; 
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• reconstructing a subject context using said target 
context, thereby generating a reconstructed subject 
context; and 

5 executing a translated version of a subject signal 

handler associated with a particular said exception using 
the reconstructed subject context. 

13. The method of claim 12, wherein the step of 
10 reconstructing a subject context comprises' reconstructing 

less than the entire subject processor state. 

14. The method of claim 12 or 13, wherein said step of 
reconstructing a subject context comprises selecting one 

15 of a plurality of subject context precision levels for 
processing said exception. 

15 . The method of claim 14 wherein the level of 
subject precision is a zero level wherein no subject state 

20 is passed to said translated subject signal handler. 

16. The method of claim 14 or 15, wherein said level 
is a level wherein only a last known stack frame is passed 
to said translated subject signal handler. 

25 

17. The method of claim 14, 15 or 16, wherein said 
level is a level wherein only a precise program counter 
value is passed to said translated subject signal handler. 

30 18. The method of claim 14, 15, 16 or 17, wherein said 

level of precision is a level wherein the precise subject 
context is passed to said translated subject signal 
handler . 
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19. The method of claim 14, 15, 16, 17, or 18, wherein 
said step of reconstructing a subject context is performed 
by proxy signal handler code. 

5 

20. The method of claim 19, wherein said proxy signal 
handler code is registered in the target code by said 
translator and wherein said translator further raises a 
flag to said proxy signal handler indicating which of said 

10 plurality of subject context precision levels is to be 
used in response to said particular exception. 

21. The method of claim 19 or 20, wherein said 
particular exception is detected during decoding of the 

15 subject code by said translator. 

22. The method of claim 21, wherein said translator 
responds to detection of said particular exception during 
decoding to plant target code which generates said target 

2 0 context and invokes operation of the proxy signal handler 
code . 

23. The method of any of claims 19 to 22, wherein said 
particular exception arises during execution of said 

2 5 target code. 

24. The method of claim 23, wherein a target operating 
system responds to occurrence of said particular exception 
during execution of said target code to pass target 

30 context to said proxy signal handler code. 

25. The method of claim 24 wherein, after receiving 
said target context, said proxy signal handler code calls 



the translator, which then invokes a selected translated 
subject signal handler. 

26. The method of any of claims 14 to 25, wherein said 
exception is caused by one of a plurality of asynchronous 
external events and wherein said exception is handled 
using a selected default level of precision assigned to 
all asynchronous events. 

27. The method of claim 26 wherein said selected 
default level is a last known stack frame. 

28. The method of any of claims 19 to 27, wherein said 
proxy signal handler code is arranged to interact with a 
subject register bank. 

29. A translator apparatus arranged to perform the 
method of any preceding claim. 

30. A computer-readable medium having recorded thereon 
instructions implementable by a computer to perform the 
method of any of claims 1 to 28. 

31. A method of handling exceptions during translation 
of program code, substantially as hereinbefore described 
with reference to the accompanying drawings. 
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ABSTRACT 



METHOD AND APPARATUS FOR PERFORMING 
ADJUSTABLE PRECISION EXCEPTION HANDLING 



An adjustable precision exception handling technique 
10 is providing for handling exceptions encountered during 
translation of subject code 17 to target code 21 at 
varying levels of precision, depending upon the particular 
type of exception encountered. As an exception signal is 
detected by the translator 19, the state of the subject 
15 processor is captured at a precision determined to be 
sufficient for the detected exception. 
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